Skip to content

Bugfixes 1-9-2026#959

Merged
SchoolyB merged 8 commits intomainfrom
bugfixes/1-9-2026
Jan 9, 2026
Merged

Bugfixes 1-9-2026#959
SchoolyB merged 8 commits intomainfrom
bugfixes/1-9-2026

Conversation

@SchoolyB
Copy link
Copy Markdown
Owner

@SchoolyB SchoolyB commented Jan 8, 2026

Summary

Batch of bug fixes from January 9, 2026.

Fixes included:

Test plan

  • All unit tests pass
  • All integration tests pass
  • Each fix tested individually before merge into parent branch

SchoolyB and others added 7 commits January 8, 2026 13:19
handleReplCommand now returns a boolean indicating whether the command
was handled, so commands like 'help' and 'clear' don't fall through to
the parser and cause undefined variable errors.

Fixes #890

Co-authored-by: Dean Tarisai <prjctimg@outlook.com>
…as decimal (#954)

- Add support for 0o/0O prefix for explicit octal literals in lexer
- Change parser to explicitly handle bases instead of auto-detection
- Leading zeros without prefix are now treated as decimal (not octal)
- 0123 is now 123 (decimal), use 0o123 for octal 83
- 09 is now valid as decimal 9
- Add comprehensive tests for octal literals and base handling

Fixes #915
The objectTypeToEZ function was missing a case for *Map, causing
the internal type name "MAP" to leak in error messages instead of
showing the proper "map[keyType:valueType]" format.

Fixes #945
…or messages (#956)

Replace all direct .Type() calls in error messages with objectTypeToEZ()
or getEZTypeName() to prevent internal Go type names like INTEGER_OBJ,
MAP_OBJ from leaking into user-facing errors.

Changes:
- evaluator.go: ~30 instances replaced with objectTypeToEZ()
- interpreter/builtins.go: updated getEZTypeName() to include typed arrays/maps
- stdlib/builtins.go: 5 instances replaced with getEZTypeName()
- math.go: 1 instance replaced with getEZTypeName()
- json.go: 2 instances replaced with getEZTypeName()

Users now see friendly type names like "int", "[string]", "map[string:int]"
instead of "INTEGER_OBJ", "ARRAY_OBJ", "MAP_OBJ".

Fixes #948
json.decode() now requires a type argument at compile time. Previously,
calling json.decode(text) without a type would return an internal 'any'
type that users couldn't actually use in their code.

Changes:
- Add E13004 error code for missing type argument
- Update checkJsonModuleCall to require 2 arguments for decode
- Update getModuleMultiReturnTypes to return nil without type arg
- Update inferJSONCallType to return false without type arg
- Remove dead code for non-existent parse/parse_file functions

Closes #947
#958)

Both getEZTypeName and objectTypeToEZ now handle all object types:
- Range → "Range<int>"
- FileHandle → "File"
- Database → "Database"
- Reference → "Ref<innerType>"
- Char → "char" (added to objectTypeToEZ)
- Byte → "byte" (added to objectTypeToEZ)

Also exports FileHandle and Database type aliases from interpreter
package for consistency.

Closes #946
…960)

- Fix io.exists/is_dir/is_file return type: remove from multi-return
  types list since they return single bool, not (bool, error) tuple
- Change os.get_env to return (string, error) tuple instead of
  string|nil for proper type checking
- Fix overflow tests to use i64 instead of int (int is arbitrary
  precision with no bounds, i64 is fixed 64-bit)
- Add warning tests section to run_tests.sh
- Update unit tests for new os.get_env API

Co-authored-by: UiJong, Yang <Scanf-s@users.noreply.github.com>
@SchoolyB SchoolyB linked an issue Jan 9, 2026 that may be closed by this pull request
@SchoolyB SchoolyB merged commit 7583773 into main Jan 9, 2026
8 checks passed
@SchoolyB SchoolyB deleted the bugfixes/1-9-2026 branch January 9, 2026 07:45
SchoolyB added a commit that referenced this pull request Apr 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment